fix(stack-prisma): reclassify EQL install as additive so fresh-database db init passes, and pin eql-3.0.4 - #820

Addresses review on #820: the install baseline must target the latest
EQL release, not 3.0.2.

- @cipherstash/eql pinned 3.0.2 -> 3.0.4 in prisma-next, cli, and stack
  (lockfile updated via the one-off cooldown bypass; @cipherstash/eql is
  already in minimumReleaseAgeExclude as a first-party package)
- the re-emitted install baseline now bakes the eql-3.0.4 bundle and
  carries BOTH upgrade invariants (3.0.2 + 3.0.4) via no-SQL additive
  carrier ops, so fresh-database `db init` still satisfies the head ref
  from the single all-additive genesis edge
- new `data`-classed 3.0.4 upgrade self-edge
  (20260728T0000_upgrade_eql_v3_3_0_4) for databases installed at an
  older bundle, walked via `migrate` only
- head ref gains the 3.0.4 invariant; descriptor wires the new edge;
  example vendored space synced; changeset added

Tests: prisma-next 345 passed (frozen-hash pins re-pinned for the
re-emitted baseline, new edge pinned); stack 1107; cli 947.

Verified live against a consumer app: fresh-database `db init` applies
the cipherstash space additively and `eql_v3.version()` reports 3.0.4.

Addresses review on #820: the install baseline must target the latest
EQL release, not 3.0.2.

- @cipherstash/eql pinned 3.0.2 -> 3.0.4 in prisma-next, cli, and stack
  (lockfile updated via the one-off cooldown bypass; @cipherstash/eql is
  already in minimumReleaseAgeExclude as a first-party package)
- the re-emitted install baseline now bakes the eql-3.0.4 bundle and
  carries BOTH upgrade invariants (3.0.2 + 3.0.4) via no-SQL additive
  carrier ops, so fresh-database `db init` still satisfies the head ref
  from the single all-additive genesis edge
- new `data`-classed 3.0.4 upgrade self-edge
  (20260728T0000_upgrade_eql_v3_3_0_4) for databases installed at an
  older bundle, walked via `migrate` only
- head ref gains the 3.0.4 invariant; descriptor wires the new edge;
  example vendored space synced; changeset added

Tests: prisma-next 345 passed (frozen-hash pins re-pinned for the
re-emitted baseline, new edge pinned); stack 1107; cli 947.

Verified live against a consumer app: fresh-database `db init` applies
the cipherstash space additively and `eql_v3.version()` reports 3.0.4.

Addresses review on #820: the install baseline must target the latest
EQL release, not 3.0.2.

- @cipherstash/eql pinned 3.0.2 -> 3.0.4 in prisma-next, cli, and stack
  (lockfile updated via the one-off cooldown bypass; @cipherstash/eql is
  already in minimumReleaseAgeExclude as a first-party package)
- the re-emitted install baseline now bakes the eql-3.0.4 bundle and
  carries BOTH upgrade invariants (3.0.2 + 3.0.4) via no-SQL additive
  carrier ops, so fresh-database `db init` still satisfies the head ref
  from the single all-additive genesis edge
- new `data`-classed 3.0.4 upgrade self-edge
  (20260728T0000_upgrade_eql_v3_3_0_4) for databases installed at an
  older bundle, walked via `migrate` only
- head ref gains the 3.0.4 invariant; descriptor wires the new edge;
  example vendored space synced; changeset added

Tests: prisma-next 345 passed (frozen-hash pins re-pinned for the
re-emitted baseline, new edge pinned); stack 1107; cli 947.

Verified live against a consumer app: fresh-database `db init` applies
the cipherstash space additively and `eql_v3.version()` reports 3.0.4.

…820 review)

Addresses Copilot review on #820. The 3.0.4 bump left three comments
describing the 3.0.2-era state:

- the install migration's invariant-carrier comment still named the baked
  bundle `eql-3.0.2` while the same sentence called the pinned release
  3.0.4
- the same file's PUBLISHED banner described the re-emit as adding one
  3.0.2 carrier, omitting the bundle bump, the second carrier, and the
  fact that the baked `installSqlSha256` changed too (not just the
  `migrationHash`)
- the baseline test was still named "two additive rawSql ops" and its
  comment described a single carrier landing at 3.0.2, while the
  assertion below it already expected three ops

Comments only — `migrationHash` covers `ops.json` and `migration.json`,
not `migration.ts`, so the published artefact identity is untouched
(frozen-hash pins still pass).

…db init additive

The lockstep test has been red since the tree released the jsonb_document_contains
rename as 3.0.5: it requires the installed @cipherstash/eql's install SQL to be
baked by some published migration, and 7ad9c9f8 was baked by none. 9b1c44d said
as much when it applied the version bump. This ships the migration it deferred.

Two artefacts carry the new bundle, and the second one breaks the append-only rule
on purpose.

20260814T0000_upgrade_eql_v3_3_0_5 is the ordinary half - a self-edge carrying
cipherstash:upgrade-eql-v3-bundle-3.0.5-v1, modelled on the 3.0.2 and 3.0.4 edges,
which is how an already-baselined database reaches the new bundle under `migrate`.

The baseline is re-emitted, which the file's own header forbids. No upgrade edge
can ever be walked by `db init`: every one of them is a self-edge, checkIntegrity
requires a self-edge to carry a data-class op, and db init runs
allowedOperationClasses: ['additive']. So a fresh database has to collect every
head-ref invariant from the genesis edge it walks, and a newly required invariant
either lands there or arrives on a second from: null edge duplicating the full
2.6 MB bundle - permanently, once per EQL release. Re-emitting was taken instead
while @cipherstash/stack-prisma@1.0.0 was 14 days old at ~253 monthly downloads,
so the blast radius was small and knowable; the changeset carries the
delete-and-re-plan instruction, and both the migration header and the plan doc
record that the second genesis edge is the correct shape once adoption is real.
The trade is to be re-argued at the next bump, not defaulted to.

The baseline moves fc495f7f -> 1ae73282 and its baked SQL 63104a81 -> 7ad9c9f8.
The 3.0.2 and 3.0.4 edges keep their own frozen digests untouched - that
separation is what makes the lockstep check meaningful rather than
self-satisfying.

Three new cases: the 3.0.5 edge's shape, that its baked SQL actually carries the
rename (jsonb_document_contains present, ste_vec_contains absent), and that the
genesis edge alone covers every head-ref invariant with all-additive ops - the
db init property the carrier ops exist for, which nothing asserted directly.

Found while doing it, and fixed here: test/live/migration-apply-live-pg.test.ts
has been broken since #820. It demanded exactly one baseline op and asserted
operationClass 'data', both stale since the carriers landed and the install op
became additive. It only runs against a live database, so CI has never seen it.
It now selects the install op by id.

Skills: stash-postgres claimed the CLI pins @cipherstash/eql to an exact version,
which stopped being true when EQL moved in-tree earlier in this PR. stash-supabase
re-states its PostgREST limits against 3.0.5 (unchanged in substance). And
packages/eql/AGENTS.md still named ste_vec_contains as a public wrapper.

Verified: stack-prisma 348 passed / 27 skipped, typecheck clean, stash 1232
passed, test:scripts 515 passed, examples/prisma typecheck clean, biome clean.
Full `pnpm test` cannot complete locally - @cipherstash/stack needs the
protect-ffi binding this machine has no cargo build for; CI builds it.